As computers have become faster and available memory has increased, software has also become more and more complex. Today, a typical software application may contain millions of lines of code. With the increased complexity of software applications, the issues associated with writing the code, a task often undertaken by large groups of programmers working concurrently, have become more numerous and difficult to resolve. Correcting mistakes in computer code during development, or “debugging,” has become particularly difficult as code complexity has increased.
When debugging an application, it is common to encounter a block of code that needs to be inspected. Typically, a programmer inserts a special instruction called a breakpoint into the block of code. A breakpoint is a special instruction inserted into code by a programmer and a software complier that halts a program during execution so that the programmer can, by means of a debugging program, examine the state of the executing code and computing system and, perhaps, determine the source of a software bug. Some blocks of code need to be inspected under certain calling scenarios and not others. Current debugging techniques only enable the developer to specify specific calling scenarios under very limited conditions. In other words, in the current state of the art, breakpoints cannot be made dependant upon a designated execution path. This limitation is particularly a problem in object-oriented programming system in which code reuse is prevalent.
For example, if “M” is a module reused by a number of other modules, “B” is a breakpoint within M and “O” is a breakpoint within a module “N” outside of module M that calls M, a user can enable breakpoint B during the halt in execution caused by breakpoint O. Of course, this procedure is awkward, could benefit from automation and does not address the issue of disabling breakpoint B once module N has finished executing.
Another available debugging technique is the use of conditional breakpoints. A conditional breakpoint is one in which the corresponding module is halted only if certain conditions are met. For example, a breakpoint “C’ may be activated only if a certain variable exceeds a predefined value. In current technology, conditional breakpoints can only depend upon conditions within the scope of the module in which the breakpoint is located.
What is needed is a system of breakpoints that can be made dependant upon the calling sequence. In other words, it would be advantageous if a particular breakpoint could be called or not depending upon the specific modules through which the breakpoint is reached.